\chapter{Perspectives d'implémentation}
Il existe de nombreuses perspectives d'améliorations possibles. Les domaines ciblés sont l'utilisation du pare-feu, les options de cryptage, le mode de chiffrement et la congestion du pare-feu.

\section{Utilisation du pare-feu}
Dans ce projet les intéractions avec le pare-feu s'effectuent par le biais d'appel système destiné au logiciel \textbf{iptables}. En donnant le contr\^{o}le au noyau l'appel système est dépendant de la plateforme. De ce faite l'utilisation de librairie pour intéragir avec le pare-feu permettrait de profiter d'un plus grand niveau d'abstraction avec le système et d'une plus forte stabilité.
 
\paragraph{}
Le logiciel iptables a été développé à partir de la librairie \textbf{libiptc} qui fournit des fonctions de communication avec \textbf{netfilter}. Ce dernier est un framework au sein du noyau linux en charge du filtrage des paquets reçus et émis sur le réseau. L'utilisation de la librairie libiptc permettrait donc d'effectuer les mêmes actions sur le pare-feu que les appels systèmes tout en respectant un fort niveau d'abstraction et de stabilité.

\paragraph{}
De plus, une règle d'iptables ne peut \^{e}tre appliquée que sur un seul protocole de communication (tcp, udp...), c'est-à-dire qu'une règle doit être créée pour chaque service demandé par le client. Cette limitation allourdit le code ainsi que la liste des règles affichées dans le système. L'intégration de la libiptc dans le code pourrait alléger le code.


\section{Choix du cryptosystème}
Actuellement le client n'a pas le contr\^{o}le sur le choix de cryptosystème à utiliser pour générer le cryptogramme\footnote{Message chiffré} . La seule option disponible est l'algorithme de chiffrement \textbf{AES} avec 
le mode d'opération CBC.

\paragraph{}
Comme vue dans la section 3.2, AES est algorithme de chiffrement par bloc. La première idée serait de proposer au client de choisir une catégorie d'algorithme, par bloc ou non, puis de lui lister tous les choix possibles de la catégorie sélectionnée. De ce faite l'utilisation de cryptosystèmes différents pour chaque utilisateur augmenterait la sécurité des échanges. Un attaquant ne pourrait alors définir avec certitude l'algorithme utilisé.

\paragraph{}
Le m\^{e}me raisonnement est alors applicable sur le choix du mode d'opération associé à l'algorithme de chiffrement.


\section{Chiffrement asymétrique}
Le programme se sert de la cryptographie symétrique pour chiffrer les échanges entre le client et le serveur. Cette technique est la plus ancienne forme de chiffrement et son principe repose sur l'utilisation d'un secret partagé entre les deux parties communicantes. Ce qui implique l'échange de ce secret avant toute usage de SPA. La perspective d'évolution est alors de trouver le moyen de sécuriser cet échange.

\paragraph{}
La solution la plus simple serait de positionner manuellement le secret chez le client et le serveur, ce qui n'est évidemment pas réaliste. En revanche implémenter un chiffrement asymétrique permettrait de résoudre ce problème. Il suffit d'affecter une clé publique au serveur qui la distribue alors à tous ses clients. Chez le client le programme peut alors chiffrer les paquets envoyés gr\^{a}ce à la clé publique du serveur sans altérer son niveau de sécurité. Comme le serveur est le seul à posséder la clef secrète, il est impossible pour un attaquant de déchiffrer le message. Cette solution offre une plus grande abstraction au client qui ne doit en aucun cas posséder de secret partagé ou de clé secrète.


\section{Congestion du pare-feu}
Pour chaque service demandé par le client, le serveur ajoute une règle d'autorisation dans le pare-feu linux. Néanmoins le serveur peut \^{e}tre sujet à des attaques de denis de service.

\paragraph{}
Un paquet udp offre une taille de donnée assez importante pour laisser la possibilité à un client de demander plus de 80 services. Si plusieurs clients tentent d'accéder à plus de 80 services, le pare-feu du serveur risque de ne pas supporter la charge. Pour contrer cette faille l'idée serait alors, soit de limiter la taille du paquet udp, soit de tronquer le nombre de services pris en compte par le serveur.
